Design Patterns Formalization

Instances <> Role Name Abstract State Strucuture Abstract Behavioral Semantics Abstract Interfaces <> Type Name Refined Abstract State Strucuture Refined Abstract Behavioral Semantics + Operation Interfaces Refined Abstract Interfaces <> Class Name Concrete State Strucuture Concrete Behavioral Semantics (Method Implementation) Instances <> <> The first layer (the role model) expresses the pattern purely in terms of highly abstract states and highly abstract behavioral semantics, forming a constraint set that captures the essential spirit of the pattern without dilution in non-essential (applicationdomain specific) details. The middle level (the type model) refines the role model adding usually-domainspecific refinements to the abstract states and semantics, and concrete syntax for operations described by the abstract semantics. The final layer (the class model) deploys the type model in application-specific terms via the specification of concrete state (attributes) and concrete semantics (method implementations) that implements the abstract state and abstract semantics, respectively. Design Patterns Formalization Constraint Diagrams EMN Technical Report 2003 26 6.3 Demonstration of ABSTRACT FACTORY pattern The GoF representation of the structure of ABSTRACT FACTORY (figure 6.5) as a class model (figure 6.7) may give the false impression that components of a design pattern are actually classes, while they are better thought in more abstract ways. Specifically, the pattern may be re-expressed as a type model, which in turn may be refined continually into a hierarchy of derived type models, each adding constraints to the type model above the hierarchy. However, when a commitment is made to concrete (rather than abstract) states and concrete method implementations, by adding more details, the class model is achieved. Figure 6.5 – Structure of ABSTRACT FACTORY according to GoF catalog Figure 6.6 – ABSTRACT FACTORY as a type model <> AbstractFactory <> Abstract Factory CreateProductA( ) : AbstractProductA CreateProductB( ) : AbstractProductB <> AbstractProductA <> AbstractProductB <> <> CreateProductA( ) CreateProductB( ) AbstractFactory CreateProductA( ) CreateProductB( ) ConcreteFactory1 CreateProductA( ) CreateProductB( ) ConcreteFactory2 ConcreteProductA2 ConcreteProductA1 AbstractProductA ConcretProductB2 ConcretProductB1 AbstractProductB Client Design Patterns Formalization Constraint Diagrams EMN Technical Report 2003 27 Figure 6.7 – ABSTRACT FACTORY deployed as a Class Model The main contribution of the type model is that it only abstracts structure from the pattern, leaving details of concrete implementation to derived class models. Thus, it is possible to see figure 6.6 as a specific realization of the type model that is sufficiently abstract to permit many other class model realizations. However, to capture only the essential spirit of the pattern, and remove nonessential features, which constraint the pattern generality, roles are utilized in the models. Roles are collaborating actors. Thus, a role model is a description of a structure of cooperating objects along with their static and dynamic properties. Constraints (on state and on behavior) in the role model must be respected by further refinements. Figure 6.8 – ABSTRACT FACTORY as a role model <> AbstractFactory <> Abstract Factory CreateProductA( ) : AbstractProductA CreateProductB( ) : AbstractProductB <> AbstractProductA <> AbstractProductB <> <> ConcreteProductA1 ConcreteProductA2 ConcreteProductB1 ConcreteProductB2 <> <> ConcreteFactory1 CreateProductA() : ConcreteProductA1 CreateProductB() : ConcreteProductB1 ConcreteFactory2 CreateProductA() : ConcreteProductA2 CreateProductB() : ConcreteProductB2